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I In the last column, I introduced you 
to the so-called WIN16, WIN32S, 
and WIN32 APIs. As you'll recall, 
we're using the term WIN16 for the 
16-bit API of Windows 3.1, WIN32 
for the expanded 32-bit API that 
was designed by Microsoft to com- 
pete with OS/2 2.0's 32-bit Pre- 
sentation Manager API, and WIN- 
32S for that subset of the WIN32 API that 
has direct counterparts in WIN16. 

At the present time, WIN32 is sup- 
ported only on Microsoft's new NT oper- 
ating system for 386 and 486 processors 
.nd MIPS machines; a full-fledged 
WIN32 implementation that runs on top 
of DOS has been promised for 1993 
(though I'm skeptical that it will ever ma- 
terialize). In the meantime, Microsoft is 
supporting WIN32S on DOS and Win- 
dows 3.x with a special loader in a VxD 
and a "thunk" layer that translates 32- 
bit API calls by the application into 16- 
bit API calls. The exact same WIN32S 
binaries run on either Windows 3.x or 
NT/WIN32. As a temporizing solution, 
this is quite reasonable, and it should mo- 
tivate many developers to move their ap- 
plications to 32-bit mode much earlier 
than they would otherwise. 

NT has many powerful and interesting 
features, but we're going to ignore them 
for a while yet and talk instead about the 
issue of source code portability between 
WIN16, WIN32S, and WIN32. Since 
WIN32S and WIN32 are supersets of 
WIN16, and WIN32S is almost exactly 
symmetric with WIN16, it's quite feasible 
to compile programs for either the 
WIN16 or WIN32 execution environ- 
rient from the same source code base. 
The flat memory model of WIN32, the 
widening of integers from 16 bits to 32 
bits, and the differences in calling con- 
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ventions are generally transparent, if suf- 
ficient attention is paid to the correct use 
of data types and handles. The other ines- 
capable differences between the 16-bit 
and 32-bit programming interfaces are 
summarized in Figure 1. 

Don't allow yourself to be intimidated 
by Figure 1; it may look like a long list 
of things to fret about, but in fact the 
items listed have surprisingly little impact 

Our sample program, a utility 
for viewing a file in hex and 

binary, demonstrates the 
surprisingly easy portability 
between the 16- and 32-bit 
Windows environments. 



on application source code. The "van- 
ished" functions are principally those 
that are CPU-architecture-dependent, 
and they must be dealt with on an individ- 
ual basis. On the other hand, the seman- 
tics of the altered APIs and altered mes- 
sages usually haven't changed, so most of 
the differences in that area can be han- 
dled by mechanical editing and condi- 
tional ttdefines in the application header 
file. For example, the changes to mes- 
sages are almost always related to param- 
eter packing — typically the movement of 
some value from lParam to wParam to 
allow for a 32-bit handle in lParam. The 
superseded functions are mostly sound 
functions that have been replaced by the 
multimedia API, or by relatively esoteric 
GDI functions related to coordinate 
spaces. 



To help convince you that this easy 
portability from WIN16 to WIN32 isn't 
just standard Microsoft marketing hype 
but is in fact achievable, I'm going to fol- 
low up last issue's WINAPP application 
skeleton with a considerably more elabo- 
rate programming example. HEXVIEW, 
which can be seen in action in Figure 2, 
is a relatively mundane utility for viewing 
the contents of a file in hex and binary. 
Looking at the utility is worthwhile, 
though, because it demonstrates many of 
the aspects of a functional Windows ap- 
plication: It has a menu and an About dia- 
log, it exploits the common dialog library, 
it performs file I/O, it selects a font, it 
paints text in its window, it maintains a 
scroll bar, and it saves and retrieves pref- 
erence information about the size and lo- 
cation of its window and the name of the 
most recent file viewed. (Just to keep the 
full picture in perspective, the important 
Windows application tasks that HEX- 
VIEW doesn 't demonstrate are keyboard 
input, Clipboard operations, drag-and- 
drop, and DDE.) You can download 
HEXVIEW from PC MagNet, archived 
as HEXVIE.ZIP. 

Pay attention now as we list all the 
ways that the HEXVIEW source code 
can be compiled and executed (see Fig- 
ure 3) without any changes whatsoever! 
If HEXVIEW is compiled with BC++ 
3.0, we get a 16-bit protected-mode NE 
binary that can run under Windows 3.x 
on 286, 386, or 486 processors; under NT 
on 386 or 486 processors using its Win- 
dows-On- Windows compatibility layer 
(WOW); or under NT on RISC proces- 
sors using emulation technology that 
Microsoft has licensed from Insignia 
Corp. If HEXVIEW is compiled with 
Microsoft's CL386, we get a 32-bit pro- 
tected-mode PE binary that can be run 
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the WIN32S translation DLLs and VxD, 
or under NT on a 386 or 486 as a native 
application. If HEXVIEW is compiled 
with the MIPS NT compiler, we get a 32- 
bit MIPS binary that can be run under 
NT on the R-4000 processor. 

SOURCE CODE OVERVIEW The source 
code for HEXVIEW is listed in Figure 
4, the header file in Figure 5, the resource 
script in Figure 6, and the module defini- 
tion file in Figure 7. The header file con- 
sists mostly of function prototypes, ex- 
cept for a few arbitrary menu identifiers 
and some conditional #defines that we'll 
return to later. The resource script con- 
tains a totally standard, totally familiar 
Windows menu definition, dialog tem- 
plate, and icon declaration; we won't dis- 
cuss their arcane syntax further here, ex- 
cept to remind you that it's the same for 
all of the target environments. 

Turning to the source file, let's sort out 
the routines by their function and when 
they're executed, then look at the intent 
of each procedure in a little more detail. 

• Application Infrastructure: WinMain, 
InitApp, Initlnstance, Termlnstance. 

• Event Handling for the Frame Win- 
dow: FrameWndProc, DoDestroy, Do- 
Close, DoVScroll, ThumbTrack, DoSize, 
DoPaint, DoCommand, DoMenuOpen, 
DoMenuAbout, DoMenuExit. 

• Event Handling for the Child Window: 
ChildWndProc, DoChildPaint. 

• Event Handling for the About Dialog 
Box: AboutDlgProc. 

• File Manipulation: OpenDataFile, 
ReadDataFile, GetByte. 

• Helper Routines: DisplayLine, Config- 
Display, Repaint, SetWindowCaption, 
SetFilePosition, UpdateFrameProfile. 

It's a bit ironic that as a C program 
becomes more modular and structured, 
the procedures within the program be- 
come shorter and more numerous, and 
the source code correspondingly more 
difficult to understand without a road 
map or code-analysis tools. Good struc- 
tured technique and modularity are, after 
all, supposed to improve the maintain- 
ability of a program, and so it does, but 
only after the usual learning curve. New- 
comers to Windows programming also 
find it strange that a Windows program 
contains routines that are apparently 
never called from the main sequence of 
execution; only after they understand 



oriented architecture does the source 
code begin to make some kind of sense. 
INFRASTRUCTURE PROCEDURES The 

procedures WinMain, InitApp, Init- 
lnstance, and Termlnstance — along with 
the C runtime library startup code, which 
is linked into the program automatically 
and is invisible to us in this source list- 
ing — can be thought of as the program's 
infrastructure. When HEXVIEW is 
launched, the startup code first receives 
control, and after performing some 
housekeeping and several calls to Win- 
dows API functions, it transfers control 
to the WinMain routine. 

WinMain calls or does not call Init- 
App according to the value of hlnstance. 
one of its parameters. Under Windows 
3.x, if hlnstance is zero, this instance of 
HEXVIEW is the only one running, and 
InitApp must be called to register the ap- 
plication's window classes. If hlnstance is 
nonzero under Windows 3.x, another in- 
stance is already running, and InitApp is 
bypassed, hlnstance is always zero in a 
WIN32 or WIN32S environment, so Init- 
App will always be called when HEX- 
VIEW is compiled as a 32-bit application. 

Following the possible call to InitApp, 
WinMain calls Initlnstance to create the 
application's frame window, size and po- 
sition the window according to saved 
preferences from a previous execution of 
the program, get a handle for a nonpro- 
portional font, allocate some memory for 
a file I/O buffer, and reopen the file that 
was being viewed when the program was 
last executed. WinMain then falls into the 
famous (or infamous) Windows event 



message queue and dispatching them t 
the appropriate window callback routine. 
When a WM_QUIT message is received, 
the "value" of GetMessage is zero and 
WinMain falls out of the loop, calls Term- 
Instance to close the file and release the 
memory allocation, and then exits back 
to Windows. Wait a minute! Now that 
we've traced through WinMain from be- 
ginning to end and looked at every proce- 
dure that it calls, we still haven't seen 
where the real work of the program is ac- 
complished! That's because the most im- 
portant logic of the program is actually 
outside the main line of execution, in the 
event-handling routines. 

EVENT-HANDLING PROCEDURES The 
front line of event handling for HEX- 
VIEW is the routine FrameWndProc. 
Whenever the user moves or clicks the 
mouse on any part of HEXVIEW's win- 
dow or hits a key while HEXVIEW has 
the input focus, or when any other event 
occurs that Windows thinks might be of 
interest to HEXVIEW, a message packet 
is placed in HEXVIEW's task queue. 
WinMain dequeues the message by call- 
ing GetMessage and passes the messag 
to FrameWndProc by calling Dispatch 
Message. (FrameWndProc was desig- 
nated as the message handler for HEX- 
VIEW's frame window as part of the 
process of registering the window class in 
InitApp. DispatchMessage looks at the 
window handle in the message, looks up 
the appropriate message' handler by 
backtracking from the window handle to 
the window class of which it is a member, 
and then "calls back" into HEXVIEW 
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1 nil 


WIN16 Functions Not 
Supported in WIN32 


WIN16 Functions Altered or 
Superseded in WIN32 


WIN16 Messages Altered or 
Superseded in WIN32 


AccessResource 


AddFontResource 


EMJ3ETSEL 


AllocDStoCSAIias 


CloseComm 


■ EMJJNESCROLL 


AllocResource 


CloseSound 


EM_SETSEL 


AllocSelector 


CountVoiceNotes 


WM_ACTIVATE 


ChangeSelector 


DeviceCapabilities 


WM_CHANGECBCHAIN 


Dos3Call 


DeviceMode 


WIVLCHARTOITEM 


FreeSelector 


DlgDirSelect 


WM.COMMAND 


GetCodeHandle 


DlgDirSelectComboBox 


WM_CTLC0L0R 


GetCodelnfo 


ExtDeviceMode 


WIVLDDEJ\CK 


GetCurrentPDB 


FlushComm 


WM_DDE_ADVISE 


GetEnvironment 


GetAspectRatioFilter 


WM_DDE_DATA 



Figure 1: Summary of the inescapable differences between the 16-bit and 32-bit programming interfaces. 
The functions in WIN32 that have no counterparts in WIN16 are not shown here. 
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at the message handler's entry point.) 

When FrameWndProc is entered, the 
various components of the message cur- 
rently being processed are on the stack: 
hWnd (the window handle), wMsg (an in- 
teger value that indicates the message 



type), and two parameters called wParam 
and lParam whose contents and signifi- 
cance depend on the message type. 
FrameWndProc looks up the message 
type in the table frameMsgs[] and, if it 
finds a match, passes the message to the 



appropriate routine. If the message type 
isn't found in the table frameMsgs[], 
FrameWndProc passes it to the Windows 
API function DefWindowProc, which 
contains code for the default behavior for 
each message type. 

The HEXVIEW procedures that are 
called by FrameWndProc are mostly 
small and straightforward. DoClose pro- 
cesses a WM_CLOSE message by calling 
UpdateFrameProfile to save the win- 
dow's current size and position and the 
current filename and file pointer, then 
forcing a WM_DESTROY message by 
calling the Windows function De- 
stroyWindow. DoDestroy processes the 
WM_DESTROY message by forcing a 
WM_QUIT message (which causes Win- 
Main to fall out of its event loop). DoSize 
reacts to a window-resizing operation by 
calculating the number of lines that will 
now fit into the window, updating certain 
global variables, and calling ConfigWin- 
dow to configure the number of output 
lines that correspond to each scroll-bar 
unit and update the scroll bar on the 
screen accordingly. 

The procedure DoCommand is called 
when FrameWndProc receives any sort 
of message from the menu bar, triggered 
by the user's mouse click on the menu 
bar or by accelerator keys for menu 
items. DoCommand decodes the mes- 
sage with the aid of the table menu- 
items[], then hands off control to Do 
MenuOpen, DoMenuExit, or DoMenu- 
About to open a file, terminate the appli- 
cation, or display the About dialog box, 
respectively. DoMenuOpen calls the 
common dialog library routine GetOpen 
FileName to get a filename and uses the 
routines OpenDataFile, ReadDataFile, 
and Repaint to open the file, initialize the 
file I/O buffer and some global variables, 
and refresh the display in the main win- 
dow. DoMenuExit responds by sending 
a WM_CLOSE message to the frame 
window, exactly as though the user had 
picked Close from the system menu, al- 
lowing shutdown processing to be unified 
in the routine DoClose. DoMenuAbout 
creates and displays the About dialog 
box, using the static dialog resource built 
into the executable file (by the resource 
compiler from the About dialog template 
in HEXVIEW.RC). Once the dialog is 
active, the callback routine AboutDlg- 
Proc grabs control until the dialog is dis- 
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Figure 2: The HEXVIEW program in action. 
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missed by clicking the OK button. 

The DoPaint routine is entered when 
a WM_PAINT message indicates that 
some part of the window needs updating. 
This message might be received because 
the window was moved, resized, iconized 
and then restored, or covered up and then 
revealed, or even because HEXVIEW in- 
tentionally sent a message to itself (in the 
routine Repaint) when a new file was 
opened or the file pointer was moved by 
the scroll-bar message-processing rou- 
tine. DoPaint obtains a device context 
(DC), selects a nonproportional font into 
the device context using the font handle 
that was originally obtained by Init- 
Instance, and then calls the helper rou- 
tine DisplayLine to format and display 
each line of output within the window. 
DisplayLine uses the helper routine Get- 
Byte to extract each binary data byte 
from the file I/O buffer for conversion 
and formatting; any file I/O that is needed 
is hidden within GetByte. 

DoVScroll is probably the most inter- 
esting message-handling routine in HEX- 
VIEW. It is called whenever there is a 
vertical scroll-bar event — whenever the 
user clicks on the scroll bar, clicks on the 
arrows at the ends of the scroll bar, or 
drags the "thumb." DoVScroll decodes 
the event type, calculates the new file po- 
sition with the aid of the helper routine 
SetFilePosition, and updates the display 
accordingly (usually by calling Repaint to 
force a WM_PAINT message). There's 
more code in DoVScroll than you'd ex- 
pect, mainly because we want to mini- 
mize the amount of time spent painting 
in the window. DoVScroll checks for 
cases where there is nothing to do or 
where it can BitBlt the current contents 



of the window up or down by 
one line (using the Windows 
API function ScrollWindow), 
and then it lets DoPaint paint 
the "missing" line. 

When the user drags the 
thumb, DoVScroll calls 
ThumbTrack to create a tiny 
child window in the middle of 
the main window, calculate the 
file offset that corresponds to 
the new thumb position, and 
send WM_PAINT messages to 
the child window's message 
handler, ChildWndProc. Child 
WndProc decodes its message 
using the table childMsgsf] and calls Do- 
ChildPaint for WMJPAINT messages to 
display the file offset as feedback for the 
user. When the user releases the thumb, 
DoVScroll calculates the new file posi- 
tion and updates the main window. The 
destruction of the child window happens 
automatically in the helper routine Set- 
FilePosition. 

FILE MANIPULATION PROCEDURES 
We've already discussed DoMenuOpen, 
which is called by Frame WndProc in re- 
sponse to a File Open menu command 
by the user. DoMenuOpen uses the com- 
mon dialog library routine GetOpenFile- 
Name to retrieve a valid filename from 
the user, then calls OpenDataFile to 
open the file and fills the file I/O buffer 
by calling ReadDataFile. OpenDataFile 
initializes certain global variables includ- 
ing the file handle and current file posi- 
tion, reconfigures the scroll bar with the 
aid of ConfigDisplay, and puts the file- 
name into the title bar by calling SetWin- 
dowCaption. OpenDataFile and Read- 
DataFile may also be called from 
Initlnstance if a filename was saved by 
a previous execution of HEXVIEW. 

From the standpoint of display logic 
(DoPaint and its helpers), the entire file 



is always accessible in memory, and any 
given byte of the file can be retrieved b 
calling GetByte with a file offset. Get- 
Byte knows how much data and which 
part of the file is currently in the file 
I/O buffer and calls ReadDataFile when- 
ever necessary to alter the contents of the 
buffer, implementing a sort of poor- 
man's virtual-memory scheme. SetFile- 
Position is called from many routines in 
the program but principally in response 
to scroll-bar events; it alters the global 
variables that indicate the current file po- 
sition for display in the window and up- 
dates the scroll-bar thumb position ac- 
cordingly, but does no file I/O. A call to 
Repaint, which typically follows SetFile- 
Position, causes DoPaint to execute via 
a forced WM_PAINT message; Do- 
Paint's calls to GetByte will cause file I/O 
to occur if it is needed. 

HELPER ROUTINES All of the helper 
routines are called indirectly by Frame 
WndProc as a result of message process- 
ing, and a few are also called by Ink- 
Instance to set up the display of a file that 
was open when HEXVIEW was last exe- 
cuted. Each of the helper routines has al- 
ready been discussed in the context o 
event handling and file I/O procedures. 

PORTABILITY CONSIDERATIONS Now 
that we've had a whirlwind tour through 
HEXVIEW, let's go back and see where 
portability considerations intrude into 
the source code. 

First, we must remember that the gen- 
eral strategy in creating the WIN32 API 
from the WIN16 API was to widen all 16- 
bit parameters to 32 bits and to replace 
32-bit segment:offset pointers with 32-bit 
flat-model near offsets. This aspect can 
be handled fairly completely by treating 
FAR as a NOOP for 32-bit code and by 
hiding the real data types behind TYPE- 
DEFs such as HWND, BOOL, INT, 
UINT, and LONG. If you look at the 



Execution Environments for HEXVIEW 



Compiled 
with 



Windows 3.x 
on a 286 PC 



Windows 3.x 
on a 386 or 486 PC 



NT on 

a 386 or 486 PC 



NT on 

a MIPS R-4000 



B C++ 3.0 





MS CL386 



Yes (native) 



Yes (as 
16-bit app) 



Yes (using 
WOW inter- 
face layer) 



Yes (using 
emulation 
technology) 



No 



Yes (using 
WIN32S DLLs 
and VxD) 



Yes (native) 



No 



M'PSCC No Nc_ 



- 



Figure 3: These are the various ways the HEXVIEW source code can be compiled and executed. 
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HEXVIEW.C 

1 of 4 



// HexView - Windows 3.x and NT/WIN32 Hex File Viewer 

// Copyright (C) 1992 Ray Duncan 

II PC Magazine * Ziff Davis Publications 



/ sizeof (x[0] ) ) 



#define dim(x) Isizeof(x) 
Wdefine EXENAMESIZE 256 
•define BUFSIZE 65520 
#define BPL 16 

•include "stdlib.h" 
•include 'windows . h" 
•include " string. h" 
•include ■ commdlg . h " 
•include "hexview.h" 

HANDLE hlnst; 

HWND hFrame; 

HWND hChild; 

HFONT hFont; 

INT CharX, CharY; 

INT LPP; 

INT BPP; 

INT Thumblnc; 

INT hFile = -1; 

char szFi leName [ EXENAMESIZE+1] ; 

HANDLE hBuff; 

LPSTR lpBuff; 

LONG ViewPtr; 

LONG FilePtr; 

LONG FileSize; 

LONG Filelndex; 

LONG TopAddr; 

LONG TopLine; 

INT winWidth,- 

char szFrameClass [ ] - "HexView"; 
char szChildClassf] = "HexViewChild" 
char szAppName [] = "Hex File Viewer- 
char szMenuNameN = "HexViewMenu" ; 
char szlconNameU = "HexViewIcon" ; 
char szlni(] = "Hexview.ini" ; 

char *szFilter(] = { 
■All Files (*.*)", 
-Executable files (*.EXE)-, "«.E; 
"Object Modules (*.OBJ)", "".OBJ 



//'Table of window messages supported by FrameWndProc ( ) 
// and the functions which correspond to each message. 

// 

struct decodeWord f rameMsgs [ ] = { 
WM_PAINT, DoPaint, 
WM^SIZE, DoSize, 
wm_C0mmand, DoCommand, 
WM^CLOSE, DoClose, 
WM_DESTROY, DoDestroy, 
WM_VSCROLL, DoVScroll, } ; 

// 

// Table of window messages supported by ChildWndProc ( ) 
// and the functions which correspond to each message. 
// 

struct decodeWord childMsgs[] = { 
WM_PAINT, DoChildPaint, } ; 



// Table of menubar item IDs and their corresponding functions. 

// 

struct decodeWord menuitems [] = { 
IDM_0PEN , DoMenuOpen , 
IDM_EXIT, DoMenuExit, 
IDM_ABOUT, DoMenuAbout, } ; 

// 

// WinMain -- entry point for this application from Windows. 

// 

INT API ENTRY WinMain ( HANDLE hlnstance, 

HANDLE hPrevInstance, LPSTR lpCmdLine, INT nCmdShow) 

< 

MSG msg; // receives message packet 



// returns no. of elements 
// max length of path+f ilename 
// size of file I/O buffer 
// bytes per line 



// module instance handle 

// handle for frame window 

// handle for child window 

// handle for nonprop. font 

// character dimensions 

1/1 ines per page 

// bytes per page 

// bytes per thumb unit 

// handle for current file 

// name of current file 

// handle for file I/O buffer 

// far pointer to file buffer 

// addr, first line current page 

// addr, start of i/o buffer 

// length of current file 

// index from thumb tracking 

// address, top of last page 

// line num, top of last page 

// width of frame client area 

// classname for frame window 

// classname for child window 

// long application name 

/ / name of menu resource 

// name of icon resource 

// initialization filename 

// filters for Open dialog 



hlnst = hlnstance,- 



if ( ! hPrevInstance) 

if ( ! InitApp (hlnstance) ) 



// save instance handle 



/ / iff irst ins tance , 

// register window class 



MessageBoxf hFrame, "Can't initialize HexView!" 

MB_ICONSTOP | MB_OK) ; 
return (FALSE) ; 



if ( ! Initlnstance(hlnstance, nCmdShow) } // create instance window 

{ 

MessageBox( hFrame, "Can't initialize HexView! " , szAppName, 



while (GetMessage (&msg, NULL, 0, 0}) 



TranslateMessage (Sjnsgl ; 
DispatchMessage (&msg) ; 



Termlnstance (hlnstance) ; 
return(msg.wParam) ,- 



// while message != WM_QUIT 



// translate virtual key codes 
// dispatch message to window 



// clean up for this instance 
// return code = WM_QUIT value 



// InitApp global initialization code for this application. 

// Registers window classes for frame and child windows. 



BOOL InitApp (HANDLE hlnstance) 



WNDCLASS wc ; 
BOOL bParent, 



bChild; 



// window class data 

// status from RegisterClass 



// set parameters for frame window class 

wc. style = CS_HREDRAW|CS_VREDRAW; // class style 

wc . lpf nWndProc = FrameWndProc; // class callback function 

wc . cbClsExtra = 0; // extra per-class data 

wc . cbWndExtra = 0; // extra per-window data 

wc. hlnstance = hlnstance; // handle of class owner 

wc.hlcon = Loadlcon (hlnst, 'HexViewIcon"); // application icon 

wc.hCursor = LoadCursor (NULL, IDC_ARROW) ; // default cursor 

wc .hbrBackground = GetStockObject (WHITE_BRUSH) ; // background color 

wc . IpszMenuName = szMenuName; // name of menu resource 

wc . IpszClassName = szFrameClass; // name of window class 



bParent = RegisterClass (&wc ) ; 



// register parent window class 



// modify some of the parameters for the child window class 

wc. style =0; // class style 

wc . lpfnWndProc = ChildWndProc; // class callback function 

wc . IpszMenuName = NULL; // name of menu resource 

wc . IpszClassName = szChildClass; // name of window class 



bChild = RegisterClass (&wc) ; 
return (bChild && bParent); 



// register child window class 
// return combined status 



// 

// Initlnstance instance initialization code for this application. 

// Gets information about system nonproportional font. Allocates memory 

// to use as file I/O buffer. Creates frame window, gets initialization 

// information (if any) from INI file (Windows 3.x) or registration 

// database (WIN32/NT) . Positions and sizes window, opens and positions 

// file if initialization info found. 

// 

BOOL Initlnstance (HANDLE hlnstance, INT nCmdShow) 

{ 

HOC hdc; 
TEXTMETRIC tm; 
RECT rect; 
char buff [80] ,- 



// handle for device context 
/ / font information 
// window position & size 
// scratch buffer 



hFrame = CreateWindowf 
szFrameClass , 
s zAppName , 

WS_OVERLAPPEDWINDOW | WS_VSCROLL, 
CW_U SEDEFAULT , CW_USE DEFAULT , 
CW_USEDEFAULT, CW_U SEDEFAULT , 
NULL, 
NULL, 

hlnstance, 
NULL) ; 



if ( IhFrame) return (FALSE) ; 



// create frame window 

// window class name 

// text for title bar 

// window style 

// default position 

// default size 

// no parent window 

// use class default menu 

/ / window owner 

// unused pointer 

// error, can't create window 



hdc = GetDC (hFrame > ; 
hFont = GetStockObjec 
SelectObject (hdc, hFo 
GetTextMetrics (hdc, & 



// get device context 
( SYSTEM_FIXED_FONT) ; 

C) ; II realize nonproportional 

■a); II font, get character size. 



CharX = tm. tmAveCharWidth; // and calculate window width 

CharY ? tm.tmHeight + tm. tmExternalLeading; 

WinWidth = (CharX * 75) + GetSystemMetrics (SM^CXVSCROLL) ; 
ReleaseDC (hFrame, hdc); // release device context 

if(!(hBuff = GlobalAlloc ( GMEM_MOVEABLE , BUFSIZE))) // allocate memory 
return ( FALSE ) ; // error, out of memory 



IpBuff = GlobalLock(hBuff ) ,- 
GetWindowRectfhFrame, &rect) ; 



// get far pointer to m< 
// get window position, size 




// read saved position/size profile for our frame window, if any 
rect. left = Get Private Prof ilelnt ( "Frame" , "xul", rect. left, szlni); 
rect. top = GetPrivateProf ilelnt ( "Frame" , "yul", rect. top, szlni); 
rect. right = GetPrivateProf ilelnt ( "Frame" , "xlr", rect. right, szlni); 
rect .bottom = GetPrivateProf ilelnt ( "Frame" , "ylr " , rect -bottom, szlni) ; 




s source code for HEXVIEW, a utility for viewing the contents of a file in hex and binary form. 
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get saved filename and file offset for display, if any 
itPrivateProf ileString( "File" , "filename" , " " , szFileName, 
EXENAMESIZE, szlni) ; 
GetPrivateProfileStringCFile" , " f ileptr " , ■ " ,buf f , sizeof (buff ) .szlni) ; 



(szFileName[0] ) 

OpenDataFilet) ; 
ReadDataFileO ; 
SetFilePosition (atol (buff) ) ; 



ShowWindow(hFrame, nCmdShow) ; 
UpdateWindow(hFrame) ; 
return (TRUE) ; 



// if filename and file offset 

// was saved from previous 

// execution, open the file 

// and set file position 



// make frame window visible 
// force WM_PAINT message 
// return success flag 



// 

// Termlnstance -- instance termination code for this application. 
// This is a general-purpose opportunity to clean up after ourselves. 

// 

BOOL Termlnstance (HANDLE hinstance) 

i 

if(hFile != -1) 

lclose(hFile) ; 



// close file if any 



.obalUnlocMhBuff ) : 
.obalFreefhBuff ) ; 
return (TRUE) ; 



// unlock the memory buffer 
// release the buffer 
// return success flag 




dProc callback function for application frame window- 

window message using table frameMsgs[] and runs corresponding 
tion. If no match found, passes message to Windows DefWindowProc ( ) . 

'AR APIENTRY FrameWndProc (HWND hWnd, UINTwMsg. UINTwParam, LONG 1 Pa ram) 

i; 

for(i = 0; i < dim(f rameMsgs) ; i++) 

{ 

if(wMsg == frameMsgs[i} .Code) 

return! (*f rameMsgs [ i ] .Fxn) (hWnd, wMsg, wParam, lParam) ) ; 



rei 



turn (DefWindowProc (hWnd, wMsg, wParam, lParam) ) j 



// ChildWndProc callback function for application child window. 

// Works like FrameWndProc, except uses table childMsgs[]. 

LONG FAR API ENTRY ChildWndProc { 

HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 

{ 

INT i; 

for(i = 0; i < dim(childMsgs ) ; i++) 
{ 

iffwMsg == childMsgs [ i ] . Code) 

return( ( "childMsgs [ i) .Fxn) (hWnd, wMsg, wParam, lParam)),- 
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fWindowProcthWnd, wMsg, wParam, lParam)); 



// 

// DoCommand — processes WM_COMMAND messages for frame window. 
// Decodes the menubar item with the menuitemstl array, then 
runs the corresponding function to process the command. 
If no match found, passes message to Windows DefWindowProc () . 

id (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



i < dim (menu it ems) 



Param == menuitems [ il .Code) 

return! ( *menuitems [ il .Fxn) (hWnd, wMsg, wParam, lParam) ) ; 



fWindowProc (hWnd, wMsg, wParam, lParam) ) ; 



// DoDestroy -- processes the WM_DESTROY message for frame window by 
// posting a WM_QUIT message to the same window, forcing WinHain 
// to fall out of the event loop. 

// 

LONG DoDestroy ( HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 

{ 

PostQuitMessage(0) ; 
return(FALSE) ; 




// 

// DoClose — processes a WM__CLOSE message for frame window by 
// saving the current window position, size, filename, and file 
// offset, then forcing a WM_DESTROY message. 

// 

LONG DoCloselHWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



UpdateFrameProfileO ; 
DestroyWindow(hWnd) ; 
return (FALSE) ; 



// save window information 
// then close down the app 



// DoVScroll — process various WM_VSCROLL messages for frame window. 
// The user can generate these messages by dragging thumb, clicking 
// in scrollbar, or clicking arrows at both ends of scrollbar. 

// 

LONG DoVScroll (HWND hWnd, UINT wMsg , UINT wParam, LONG lParam) 



RECT rect; 

switch(LOWORD(wParam) ) 
{ 

case SB_TOP: 

if (ViewPtr) 



// LOWORD is vital for Win32 



// go to top of file if 

// we aren't there already 



SetFilePosition(fl) ; 



case SB_BOTTOM: 

SetFilePosition (FileSiz 
Repaint ( ) ; 



// go to bottom of file if 
//we aren't there already 



case SB_LINEUP: 
if (ViewPtr) 



// scroll up by one line if 
//we aren't already at top 



SetFilePosition(ViewPtr - BPL) ; 
ScrollWindowlhWnd, 0, CharY, NULL, NULL); 
UpdateWindow(hWnd) ; 



e SB_LINEDOWN: 
if (ViewPtr < TopAddr) 



// scroll down by one line if 
// we aren't already at bottom 



SetFilePositionfViewPtr + BPL); 
ScrollWindowlhWnd, 0, -CharY, NULL, NULL) ; 
GetClientRect (hWnd, &rect) ; 
rect. top = max(0, (LPP-1) * CharY); 
InvalidateRect (hWnd, Srect, TRUE); 
UpdateWindow(hWnd) ; 



// scroll up by one page 



// scroll down by one page 



case SB_PAGEUP: 

SetFilePosition (ViewPtr - BPP) ; 

Repaint ( ) ; 

break; 

case SB_ PAGEDOWN: 

SetFilePosition (ViewPtr + BPP) ; 
Repaint ( ) ; 
break ; 



case SB_THUMBPOSITION: // reposition file by thumb 

SetFilePosition (Thumblnc * (LONG) THUMBPOS) ; 
Repaint ( ) ; 
break ; 



case SB_THUMBTRACK : 

ThumbTrack (THUMBPOS) ; 



// track drag of thumb 



return (FALSE) ,- 



// 

// DoPaint process WM_PAINT message for frame window by 
// painting hex and ASCII data dump for file offsets that fall 
// within the window. We make no attempt to optimize this for 
// painting regions that are smaller than the window. 

// 

LONG DoPaint (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



HDC hdc; 

PA INT STRUCT ps; 

INT i; 



hdc 
Sele 



= BeginPaint (hWnd, &ps) ; 
:tObject'.hdc. hFont) ; 



if(hFile != -1) 
{ 

forfi = 0; i < LPP; i ++ ) 



// scratch device context 
// scratch paint structure 



// get device context 
// realize nonprop. font 



// paint all lines that 
// fall within the window 
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DisplayLine (hdc , i ) ; 



EndPaint (hWnd, &ps) ; 
return (FALSE) ; 



// release device context 



// DoChildPaint -- process WM_PAINT message for child window. 
// These occur during thumb drag,- we put up a tiny window that 
// displays the file offset corresponding to the thumb position. 
// 

LONG DoChildPaint I HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 
( 

HDC hdc; 
PA I NT STRUCT ps ; 
RECT rect; 
char buff [256] ; 



hdc = BeginPaint (hWnd, &ps); 
GetClientRect (hWnd, fcrect) ; 
SelectObject [hdc, hFont) ; 
wsprintf (buff , "%081X", Filelndex) ; 
DrawText (hdc, buff. 



// get device context 

// get client area dimensions 

// select nonproportional font 

// format file index from thumb 

// paint index into window 



irect, DT_C ENTER [ DT_VCENTER | DT_SINGLELINE) ; 
EndPaint (hWnd, &ps) ; // release device context 

return (FALSE) ; 



// 

// DoSize -- process WM_SIZE message for frame window by calculating 
// the number of lines per page and bytes per page for new window size. 
// Also reposition the display if we were already at end of file and 
/ / the window grew . 

// 

LONG DoSize (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



LPP = HIWORD | lParam) / CharY; 

BPP = LPP * BPL; 

ConfigDi splay ( ) ; 

if (ViewPtr > TopAddr) 

SetFilePosition(TopAddr) ; 
return (FALSE) ; 



// calc lines per page 

// calc bytes per page 

// calc display parameters 

// make sure window refilled 



/.' DoMenuOpen -- process File-Open command from menu bar. All 
// the hard work is done by the OpenFile common dialog. 

U 

LONG DoMenuOpen (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 
{ 

OPENFILENAME ofn; // used by common dialogs 



szFileName[0) 



* \0' ; 



// init filename buffer 



ofn. IStructSize = sizeof (OPENFILENAME) ; // length of structure 

ofn.hwndOwner = hWnd; // handle for owner window 

ofn.lpstrFilter = szFU.ter [0] ,- // address of filter list 

ofn. IpstrCustomFilter = NULL; // custom filter buffer address 

ofn.nFilterlndex = 1; // pick default filter 

ofn. IpstrFile = szFileName; // buffer for path+f ilename 

ofn.nMaxFile = EXENAMESIZE ; // length of buffer 

ofn.lpstrFileTitle = NULL; // buffer for filename only 

ofn. IpstrlnitialDir = NULL ; // initial directory for dialog 

ofn. IpstrTitle = NULL; // title for dialog box 

Ofn. Flags = 0FN_PATHMUSTEXIST I OFN_FILEMUSTEXIST; 

ofn.lpstrDefExt = NULL; // default extension 



// display open dialog 

// open file for viewing 
// initialize data buffer 
// force display of data 



if (GetOpenFileName (&ofn) ) 
{ 

OpenDataFileO ,- 
ReadDataFileO ; 
Repaint ( ) ; 



return (FALSE) 



// DoMenuExit -- process File-Exit command from menu bar. This 
//is simply handled by sending a WM_CLOSE message as though Clo 
// had been picked on the System menu to shut down the app. 
// 

LONG DoMenuExit (HWND hWnd. UINT wMsg, UINT wParam, LONG lParam) 
{ 

SendMessage (hWnd, WM_CLOSE, 0, 0L) ; 
return (FALSE) ; 



// DoMenuAbout -- process File- About command from menu bar. We 
// allocate a thunk for the dialog callback routine, display the 
// dialog, then release the thunk after the dialog is dismissed. 



LONG DoMenuAbout (HWND hWnd, UINT wMsg, UINT wParam, LONG lParam) 



lpProcAbout = MakeProcInstance ( (WNDPROC) AboutDlgProc, hlnst) ; 
DialogBoxfhlnst, "AboutBox", hWnd, lpProcAbout) ; 
FreeProc Instance (lpProcAbout) ; 
return (FALSE) ; 



// AboutDlgProc — This is the callback routine for the About... dialog. 

// 

BOOL FAR APIENTRY AboutDlgProc ( HWNDhwnd, UINTmsg, UINTwParam, LONG lParam) 

{ 

if ( (msg==WM_COMMAND) && (wParam==IDOK) ) // dismiss dialog if OK 

EndDialoc (hwnd, 0); // button was clicked, 

return(FALSE) ,- // otherwise do nothing 



// SetWindowCaption -- concatenate the filename with the application 
// name, then update the frame window's title bar. 



VOID SetWindowCaption (char * szFilename) 
{ 

char szTemp[EXENAMESIZE+l] ; 

strcpy (szTemp, szAppName) ; 
strcat (szTemp, " - •) ; 
strcattszTemp, szFileName) ,- 
SetWindowTextfhFrame, szTemp) ; 



// get application name 

// add separator 

// add filename 

// put result into title bar 



// 

// Repaint — force refresh of formatted output in main window. This 
// gets called at various points when the file position is changed. 



VOID Repaint (VOID) 
{ 

InvalidateRect (hFrame, NULL, TRUE) ; 



// repaint entire window 



// SetFilePosition - called during processing of various vertical scrollbar 
// messages to set ViewPtr to a valid value. 



VOID SetFilePosition (LONG NewViewPtr) 

{ 

if (hChild) 

{ 

DestroyWindow(hChild) ,- 
hChild = (HWND) 0; 



if (hFile == -1) 
return; 

ViewPtr = NewViewPtr & 0X0FFFFFFF0 ; 

if (ViewPtr > TopAddr) 

ViewPtr = TopAddr; 
if(ViewPtr < 0) 

ViewPtr = 0; 

SetScrollPos [hFrame, SB_VERT, 
ViewPtr/Thumblnc, TRUE) ; 



// destroy the child window 
// if it happens to be active 



// bail out if no file open 

// offset is multiple of 16 

// enforce legal file offset 

// set thumb on scrollbar 



// Conf igDisplay -- Configure various display parameters and scrollbar 
// range according to current window size and file size. 

// 

VOID Conf igDisplay (VOID) 
{ 

// calc address and line number of first line, last page 
TopAddr = max) ( (FileSize + 15) & 0X0FFFFFFF0) - BPP, 0) ; 
TopLine = TopAddr / BPL; 

// calculate bytes per scrollbar increment 
Thumblnc = BPL * ( [TopLine/32767 ) + 1); 

// configure vertical scrollbar or make it disappear if not needed 
if(BPP >= FileSize) // file fits within window 

{ 

SetScrollRange (hFrame, SB_VERT, 0, 0, FALSE); 
SetScrol lPos ( hFrame , SB^VERT , , TRUE ) ; 
if (ViewPtr) SetFilePosition(B) ; 

} 

else // file is too big for window 

( 

SetScrollRangefhFrame, SB_VERT , 0, ( (TopLine-BPL) /Thumblnc ) , FALSE); 
SetScrollPos (hFrame, SB_VERT, ViewPtr/Thumblnc, TRUE) ,- 



ThumbTrackO - called during processing of WM_VSCROLL message to track 
thumb position, also forcing update of file offset in child window. 
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RECT rect; 

INT SizeX = CharX * 10; 
INT SizeY = CharY * 2; 

if (IhChild) 
{ 

GetClientRect (hFrame, &rect) ; 



// calc size of child window 

// create child window 

// get client area of frame 



hChild = CreateWindowf // create child window 

szChildClass, // window class name 

NULL, // text for title bar 

WS_CHILD | WS_BORDER | WS_VISIBLE, // window Style 



(rect . right-SizeX) / 2, 
(rect.bottom-SizeY) / 2, 
SizeX, 
SizeY, 
hFrame, 
( HMENU) 1, 
hlnst, 
NULL) ; 



// x position 

// y position 

// window width 

// window height 

// frame is parent window 

// child window ID 

// window owner module 

// unused pointer 



// calculate file location to display, force repaint of child window 
Filelndex = minULONG) pos * (LONG) Thumblnc, TopAddr) ; 
InvalidateRect(hChild, NULL, TRUE) ; 



// 

// DisplayLine -- format and display a single line of hex/ ASCII dump 
// using the device context and relative window line number supplied 
//by the caller. The file data offset is calculated from the 
// relative window line and the offset corresponding to the line 
// currently at the top of the window. 
// 

VOID DisplayLine IHDC hdc, INT line) 
{ 

INT i; 

char buff [256] , c, *p; 
LONG x; 

ifUViewPtr + (LONG) line*BPL) < FileSize) 
{ 

// format file offset as 8-digit hex number 
p = buff + wsprintf (buff , "%081X ", ViewPtr 



(LONG) line*BPL) ; 



// format this 16-bytes as hex data 
for(i = 0; i < BPL; i++) 



x = ViewPtr + (LONG) (line * BPL) + i ; 



if(x < FileSize) 

p += wsprintf(p, "%02X ", 

else 

p += wsprintf (p, " • } ; 



GetByte(x) & 0x0ff) ; 



// format "same 16-bytes as ASCII, using 
for(i = 0; i < BPL; i++) 



ViewPtr + (LONG) (line * BPL) + i ; 



for control characters 



if(x < FileSize) 



c = GetByte (x) ; 
if(c < 0x20) 



else c 
*p++ = » 



// append a null byte, then paint the formatted data 
line*CharY, buff, strlenfbuff ) ) ; 



*P 

TextOuUhdc, 



// GetByte -- retrieve data byte from file I/O buffer, performing 
// disk I/O as necessary. This is a simple-minded virtual memory 
// scheme when file is larger than buffer. 



if(!((addr >= FilePtri fc& (addr < [FilePtr + BUFSIZE)))) 
{ 

FilePtr = (addr - (BUFSIZE/2)) & 0X0FFFFFFF0; 
if (FilePtr < 0) FilePtr = 0; 
ReadDataFile {) ; 

} 

returndpBuf £ [addr - FilePtr]); 



// OpenDataFile -- open specified file for viewing, save handle. The 

// filename was previously placed in szFileName by OpenFile common dialog. 



VOID OpenDataFile (VOID) 



if(hFile != -1) 

_lclose(hFile) ; 



hFile = _lopen(szFileName, OF_READ) ; 
if (hFile == -1) 



// close previous file if any 

// try and open the new file 
// bail out if no such file 



MessageBox (hFrame, "Can't open file!", szAppName, MB_lCONSTOP | MB_OK) ,- 
return; 



FileSize = _llseek (hFile, 0, 2); 
ViewPtr = 0; 

SetWindowCaption (szFileName) ; 



// get size of file 

// reset window address pointer 

// reset file i/o pointer 

// calc display parameters 

// update title bar 



// ReadDataFile -- read data from specified file to I/O buffer, using 
// current file position set by caller. 



VOID ReadDataFile (VOID) 



_llseek(hFile, FilePtr, 0) ; 
_lread(hFile, lpBuff, BUFSIZE); 



// bail out if 



// position file pointer 
// read the file 



// updateFrameProfileO — Update frame window profile in INI file 

// (if Win 3.x) or registration database (if NT/WIN32) by saving the 

// current window position, size, name of file being displayed, file offset. 

// 

VOID UpdateFrameProfile(VOID) 
{ 

RECT rect; 
char temp[20] ; 



if (Islconic (hFrame) j| IsZoomed (hFrame) ) return; 
GetWindowRect (hFrame, &rect) ,- 



wsprintf (temp, "%d" , rect. left) ; 
WritePrivateProf ileString ( "Frame " 



wsprintf ( temp , " %d" , rect . top) ; 
WritePrivateProf ileString ( "Frame" 



wsprintf ( temp, "%d" , rect .right) ; 
WritePrivateProf ileString ( "Frame" 



wsprintf ( temp, "%d" , rect .bottom) ; 
WritePrivateProf ileString ( "Frame " 



WritePrivateProf ileString ( "File" 



wsprintf (temp, "%ld" , ViewPtr) ; 
WritePrivateProf ileString ( "File" , 



// get position of frame window 

■xul", temp, "HexView.ini"); 

"yul", temp, "HexView.ini"); 

"xlr", temp, "HexView.ini"); 

"ylr" , temp, "HexView. ini" ) ; 
" filename" , szFileName, "HexView. ini " ) ; 

" f ileptr " , temp, "HexView. ini " ) ; 



variable declarations and at the function 
prototypes and declarations, you'll see 
that they almost uniformly use TYPE- 
DEFs in preference to real or native data 
types. You'll also notice that a few of the 
TYPEDEFs are strategically remapped 
for the two different execution environ- 
ments in the HEXVIEW.H header file 



(the remainder are handled in WIN- 
DOWS.H, which will handle all of them 
in the final versions of the development 
systems). 

Second, we must take into account the 
different calling conventions in WIN16 
and WIN32. WIN16 applications use a 
mixture of the CDECL calling conven- 



tion (parameters are pushed right to left, 
and the caller clears the stack) and the 
PASCAL calling convention (parame- 
ters are pushed left to right, and the 
called item clears the stack). In generr' 
routines that are entered directly froi. 
Windows (message and dialog callbacks) 
are declared as FAR PASCAL, while the 
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// HexView.H -- Header File for HexView.C 



#i£ !de£ined(WIN32l 

•define WIN16 TRUE 
•define WIN31 

• define INT int 

• define UINT WORD 
•define APIENTRY PASCAL 
•define WNDPROC FARPROC 
•define THUMBPOS LOWORD(lparam) 



•define WIN16 
•define THUMBPOS 



FALSE 

HIWORD(wParam) 



struct decodeword { 
UINT Code; 

LONG CFxnMHWND, UINT, 

•define IDM_OPEN 100 

•define IDM_EXIT 101 

•define IDM„ABOUT 102 



UINT, LONG); ) 



// structure associates 
// messages or menu IDs 
// with a function 



// Function prototypes 

INT APIENTRY WinMain (HANDLE , HANDLE. LPSTR, INT); 

BOOL InitApp (HANDLE) ; 

BOOL Initlnstance (HANDLE, INT) ; 

BOOL Termlnstance (HANDLE) ; 

LONG FAR APIENTRY FrameWndProc ( HWND , UINT, UINT, LONG) ; 

LONG FAR APIENTRY Chi ldWndProc (HWND, UINT, UINT, LONG) ; 

BOOL FAR APIENTRY AboutDlgProc (HWND, UINT, UINT, LONG) ; 

LONG DoDestroyiHWND, UINT, UINT, LONG); 

LONG DOC1 OS e( HWND, UINT, UINT, LONG); 

LONG DoPaint I HWND, UINT, UINT, LONG); 

LONG DoChildPaint (HWND, UINT, UINT. LONG); 

LONG DoSize (HWND, UINT, UINT, LONG); 

LONG DoCommand (HWND, UINT, UINT, LONG); 

LONG DoVScroll (HWND, UINT, UINT, LONG); 

LONG DoMenuOpen (HWND, UINT, UINT, LONG) ; 

LONG DoMenuExit (HWND, UINT, UINT, LONG); 

LONG DoMenuAbout ( HWND , UINT, UINT, LONG); 

VOID OpenDataFile(VOID) ; 

VOID ReadDataFile (VOID) ; 

VOID Setwindowcaption (char *); 

VOID Repaint (VOID) ; 

VOID SetFilePositionlLONG) ; 

VOID Conf igDisplay(VOID) ; 

VOID ThumbTrack ( INT) ; 

VOID DisplayLinelHDC hdc, INT line); 

char GetByte ( long) ; 

VOID UpdateFrameProfile(VOID) ; 




Figure 5: This is the C-language header file for the HEXVIEW utility. 



procedures that are called only from 
within the application itself are declared 
as NEAR or FAR CDECL. 

In WIN32, on the other hand, all calls 
are NEAR because of the flat memory 
model, and by default the compiler uses 

hybrid calling convention named 
STDCALL where parameters are 
pushed right to left but the callee clears 
the stack. These differences are disguised 
in the source code by again treating FAR 
as a NOOP for 32-bit code and by hiding 
the actual calling convention beneath 
idefines such as APIENTRY, CALL- 
BACK, and WNDPROC. 

Amazingly, if we've been careful not 
to use any of the API functions in our 
program that are not completely sym- 
metric between WIN 16 and WIN32, the 
masking of data types and calling conven- 
tions handles about 90 percent of the 
portability considerations for WIN16 and 
WIN32. 

Message packets and message-pa- 
rameter packing constitute most of the 
rest of our worries. WIN16 message 
packets have three 16-bit components 
(hWnd, wMsg, and wParam) and one 32- 
bit component (lParam). WIN32 mes- 
sage packets have four components with 
the same names, but all are 32-bit. Just 
as with the API function parameters, this 
'Tference is concealed behind TYPE- 
_>EFs (UINT and LONG). 

The issue of parameter packing is a 
little more tricky. We first look at all the 



messages processed by routines intrinsic 
to our program (these are nicely summa- 
rized in the tables frameMsg[] and 
childMsgs[]) and compare them to the list 
of messages in Figure 2 that were re- 
defined for WIN32. The one message 
that turns up as a potential problem for 
HEXVIEW is WM_VSCROLL. Turn- 
ing now to the programmers' references 
for WIN16 and WIN32, we find the fol- 
lowing information: 

•WIN16 WMLVSCROLL: wParam = 
scroll event type (SB_LINEUP, 
SB_PAGEUP, and so forth); lParam = 
window handle in high word, thumb posi- 



tion in low word (if applicable). 
•WIN32 WM_VSCROLL: wParam = 
scroll event type (SB_LINEUP, 
SB_PAGEUP, and so forth) in low word, 
thumb position in high word (if applica- 
ble); lParam = window handle. 

Some of these differences are easily 
handled with the conditional #defines of 
the general form: 

#if defined (WIN32) 

♦define THUMBPOS HIWORD (wParam) 

#else 

♦define THUMBPOS LOWORD (lParam) 
#endif 



HEXVIEW.RC 

Complete Listing 

// Resource script for HEXVIEW.C 
♦include "windows. h" 
♦ include "hexview.h" 
HexViewIcon ICON hexview.ico 
HexViewMenu MENU 
BEGIN 

POPUP "&File" 
BEGIN 

MENUITEM "&Open", IDM_OPEN 
MENU IT EM "E&xit", IDM_EXIT 
MENUITEM SEPARATOR 
MENUITEM "A&bout", IDM_ABOUT 

END 

END 

AboutBox DIALOG 22, 17, 126, 53 
CAPTION "About HexView..." 

STYLE DS_MODALFRAME \ WS_CAPTION | WS_SYSMENU 
BEGIN 

ICON "HexViewIcon", -1, 7, 8, 16, 16, WS_CHILD | WS_VISIBLE 
CTEXT "Hex File Viewer 1.0", -1, 33, 6, 84, 8 
CTEXT "\251 1992 Petit Mai Software", -1, 32, 16, 87; 9 
CONTROL "OK", IDOK, "BUTTON", WS_GROUP, 47, 35, 32, 14 




figure 6: This is the resource script for the HEXVIEW utility. 
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PROGRAMMING 

Power Program m ing 



then referencing the symbol THUMB- 
POS in the source code wherever the 
thumb position is needed. (Microsoft rec- 
ommends use of its "message cracker" 
macros instead, but I found them ugly 
and clumsy, and gave up on them almost 
immediately.) The remainder of environ- 
mental differences between WM_V- 
SCROLL messages are accounted for by 
using LOWORD (wParam) whenever 
the scroll event type is examined; the 
LOWORD does no harm in WIN16 and 
ensures the proper isolation of the scroll 
event type in WIN32. 

One very important divergence be- 
tween the WIN 16 and WIN32 environ- 
ments, which does not show up in our 
HEXVIEW code at all, is the handling 
of the information that is stored and re- 
trieved by the Windows functions Write- 
PrivateProfileString, GetPrivateProfile- 
String, and GetPrivateProfilelnt. In 
Windows 3.x, this information is stored 
in a plain ASCII text file named (in this 
case) HEXVIEW.INI in the C:\WIN- 
DOWS directory. Under NT, the infor- 
mation is stored in an indexed binary da- 



tabase on a per-user basis, protected by 
access control lists. 

As it stands, HEXVIEW is a WIN32S 
application and takes no special advan- 
tage of NT's capabilities when running as 
a 32-bit program. NT-specific enhance- 
ments can easily be added via conditional 
compilation, but these will tend to make 
the source code more confusing, so the 
potential performance gains must be 
weighed against the damage to maintain- 
ability. Our first inclination might be sim- 
ply to make the file I/O buffer a lot bigger 
under WIN32 (since the flat memory 
model makes access to multimegabyte 
data objects very efficient). But this 
would probably slow the program down, 
rather than speed it up. The allocation 
of a huge buffer will stir up a lot of activ- 
ity in the system's virtual memory man- 
ager, and in the case of very large 
files HEXVIEW will waste time reading 
data that is never needed. A much better 
solution under NT would use its mapped 
file functions, which essentially associate 
offsets within a disk file with a range of 
memory addresses, and would shift the 



HEXVIEW. DEF 

Complete Listing 

NAME HexView 

DESCRIPTION 'HexView - Windows Hex Vi 

EXETYPE WINDOWS 

STUB 1 WINSTUB . EXE 1 

CODE PRELOAD MOVEABLE 

DATA PRELOAD MOVEABLE MULTIPLE 

HEAPSIZE 32768 
STACKSIZE 8192 




EXPORTS 

FrameWndProc 
Abo^LDlgProc 
Chi ldWndProc 



Figure 7: This is the module definition file for the 
HEXVIEW utility. 

entire burden of file I/O onto the sys- 
tem's paged memory manager. 

THE IN-BOX Please send your ques- 
tions, comments, and suggestions to me 
at any of these electronic-mail addresses: 
PC MagNet: 72241,52 
MCI Mail: rduncan 
BIX: rduncan 

Internet: duncan@csmcmvax.bitnet □ 



Turn your 
excess inventory 
into a tax break 
and help send needy 
kids to college. 

Call for your 
free guide 
to learn how donating your 
slow moving inventory 
can mean a generous 
tax write off 
for your company. 

Call 708-690-0010 

Peter Roskam 
Executive Director 






P.O. Box 3021, Glen Ellyn, IL 60138 
Fax (708) 690-0565 



Claudia did not have the finances to finish college. Excess inventory 
donations to EAL gave her the scholarship she needed to 
graduate. Claudia is now with a leading financial trading firm, 
happily married with twin daughters. 



Excess inventory today. ..student opportunity tomorrow 



